Debugging usually, but not always, involves the use of a debugger, a powerful tool that allows the programmer to observe the run-time behavior of a program and determine the location of semantic errors. Certain debugging features may also be used that are built into the language and its associated libraries. Many programmers are first exposed to debugging when they attempt to isolate a problem by adding calls to output functions to their code. This is a perfectly legitimate debugging technique, but once the problem(s) have been located and fixed, all those extra function calls will have to be removed from the code. It might be the case that by adding new code, even a single call, such additions change the behavior of the code that is being debugged.
An alternative approach is the use of a debugger, a computing application which reads and analyzes code for problems and errors. In using a debugger, programmers are availed the ability to examine the content of variables in a program without having to insert additional calls to output the values. Additionally, with the use of debugger, breakpoints can be inserted in the program code to halt execution at the point of interest. When the program is halted (in break mode), local variables and other relevant data can be examined using debugger facilities (e.g. watch window). Not only can the contents be viewed while in break mode, the contents can be changed and/or edited.
Specifically, a breakpoint is a signal that tells the debugger to temporarily suspend execution of a program at a certain point. When execution is suspended at a breakpoint, the program is said to be in break mode. Entering break mode does not terminate or end the execution of your program. Execution can be resumed (continued) at any time.
Break mode can be thought of as being like a timeout at sporting event. All the players remain on the field (functions, variables, and objects remain in memory), but their movements and activities are suspended. During the timeout, the referee can examine their positions and states to look for violations (bugs). The referee has the power to make adjustments to the players during the timeout. While in break mode adjustments to the program can be made. For example, the value of a variable may be changed. Also, the execution point can be moved, which changes the statement that will be executed next when execution resumes.
Breakpoints provide a powerful tool that allows the suspension of program execution where and when it is desired. Rather than stepping through the code line-by-line or instruction-by-instruction, the program can be set to run until it hits a breakpoint, then start to debug. This speeds up the debugging process enormously. Without this ability, it would be virtually impossible to debug a large program.
Many program languages have statements or constructs that suspend execution and put the program into break mode. Visual Basic, for example, has the Stop statement. Breakpoints differ from these statements because breakpoints are not actual source code that has to be added to a program. The breakpoint statement is not typed into a source window, rather it is requested through some general debugger interface, and the debugger, in turn, sets the breakpoint.
In the runtime context of a computing environment having pluggable components (e.g. data transformation system (DTS)), debugging becomes more complicated. (Specifically, debugging is difficult because within a runtime with pluggable components is a unique debugging problem because the runtime does not have the source code of the component to work against. Moreover, much of the execution of the runtime packages (e.g. DTS packages) happens outside run-time. Also, tasks have control of their own execution which means they control when they are paused (e.g. for debugging purposes). For the runtime to pause a particular task, the runtime (a computing application that accompanies a data file for displaying and or running the data file) is required to be in cooperation with that particular task. Current practices have addressed debugging at runtime but have not tackled the debugging of pluggable components at runtime as the cooperation between runtime and tasks has not been addressed. Simply, the runtime has little control over the execution of pluggable components.
From the foregoing, it is appreciated that there exists a need for systems and method that overcome the prior art.